While there is an increased demand for a packet technology-based network, IP network services based on the next generation network (NGN) scheme are expected to be driven further in the future. As a vehicle in this scheme, a lower layer that is highly compatible with IP applications, such as Ethernet and MPLS (Multi-Protocol Label Switching), is required. On the other hand, in order for the NGN to serve as the next-generation infrastructure, a feeling of reliability and a feeling of security as the infrastructure are required and thus it is important to establish a network having quality and reliability comparable with the existing legacy network in both an access system and a relay system.
In such background, the OAM for Ethernet networks is already under study in each standardization organization. For the OAM (Operation, Administration, and Maintenance) regarding the Ethernet, a mechanism recommendation Y.17ethoam (Non-Patent Document 1) and a linear switching recommendation G.8031 (Non-Patent Document 2) are under study in ITU. Moreover, in IEEE, the mechanism of Ethernet OAM is under study in p802.1ag (Non-Patent Document 3). These organizations promote cooperation and are attempting to unify the concepts and the formats.
In maintaining a network as the concept for managing the network, the maintenance person needs to configure the maintenance range (i.e., maintenance entity). This maintenance range differs in topologies depending on the functionality of OAM and the management scope of the administrator. For example, in performing the linear switching, the maintenance range becomes a point-to-point configuration, while in checking the connectivity in the range of a certain domain, the maintenance range becomes a two dimensional-like configuration. The OAM flow needs to be run between the end points of this maintenance range. However, since the original Ethernet architecture is connectionless, a technique to identify a route at each node within the network is required.
The maintenance range (Maintenance Entity: ME) of Ethernet is a range in which an OAM packet flow is inserted and terminated. The ME is a name when the entities are in the form of point-to-point, while when the entities are managed in a plane, the ME is called a management entity group (MEGroup: MEG). MEG may be in the form of a plurality of point-to-points or a set of multipoints. Each MEG is managed using an MEGID identifier. The MEG exists within a management domain (VLAN (Virtual Local Area Network) or the like) that is distinguished by the service or the like.
In the Ethernet OAM, the ME is nested (a plurality of levels of maintenance entities (currently defined as 8 levels) can be configured for each maintenance range. The maintenance range of a lower level is included and defined in the range of the maintenance of an upper level), so that each ME is managed with an ME level identifier. At present, up to 8 levels can be obtained and the OAM flow is defined for each ME level. The ME identified by each ME level is independent from each other, and has filtering functions as follows.
a) In an OAM-flow inserting point, if an OAM packet entering from the outside is the OAM packet of an upper level, it is allowed to pass therethrough, and if it is the OAM packet of the same or lower level, it is discarded.
b) In an OAM-flow separation point, if an OAM packet from the inside of the ME is the OAM packet of an upper level, it is allowed to pass therethrough, and if it is the OAM packet of the same or lower level, it is terminated appropriately.
As the end point for terminating the OAM flow, an ME end point (MEP), and an ME intermediate point (MIP) are defined. The MEP terminates all the OAM flows for each ME level. On the other hand, the MIP terminates the OAM flow that is used in a specific range for each ME level. As the functionality of OAM, CC (Continuity Check) for connection check, switching (APS), AIS (Alarm Indication Signal), a loop back (LB), a link trace (LT), and the like are under study.
The functionality of OAM is roughly grouped into a function to be transmitted/received only between MEPs and a function that can be terminated at MIP. The former is called a proactive OAM because it is assumed to be configured mainly when a service starts. The latter is called a diagnosis OAM, an on-demand OAM, or the like because it is used in the diagnosis for fault isolation or the like. For example, CC, APS, AIS, or the like belong to the proactive OAM, while LB and LT are grouped into the diagnosis OAM. In particular, the periodically driven CC frame also contains other functionality of OAM, such as performance information, RDI (Remote Defect Indication) information, and the like, which are also used in the application for obtaining the configuration information at the time of initial connection and establishing a database (CC Database: CCDB).
For DA (Destination Address) of an OAM frame, a unicast or a multicast can be considered, however, from a viewpoint of an operator who manages the network, it is not preferable to use the unicast DA that is changed every time the equipment and materials are replaced. For this reason, the multicast is recommended except in special applications. The examples of the unicast include a LB request, a reply to LB, and a reply to LT. Moreover, a method has already been invented for identifying the ME level using the multicast DA. An ME level identifier field exists in the OAM frame, and is intended to be used as an auxiliary measure for identifying the DA, for the purpose of reducing the internal processing of an MPU and the like. Furthermore, MIP needs to allow the proactive OAM to pass therethrough without processing the frame (simple operation). In order to facilitate this operation, two types of DAs: DA for proactive OAM; and DA for diagnosis OAM, are defined. That is, 16 (=8 levels×2) types of multicast DAs are defined for the OAM.
Non-Patent Document 1: “Draft Recommendation Y.1731-OAM Functions and Mechanisms for Ethernet based Networks” ITU-T SG13, November 2005.
Non-Patent Document 2: “Draft Recommendation G.8031-Ethernet Protection Switching” ITU-T SG15, November 2005
Non-Patent Document 3: “Virtual Bridged Local Area Networks-Amendment 5: Connectivity Fault Management” IEEE P802.1ag/D5.2, December 2005